@herve

So, what I'd like to see is that we can run this against a store even if that store doesn't have the e2e tests installed.

So detect-e2e currently gates this against running if one isn't found, let's actually install the sample data and the e2e tests and attempt to run them.

@herve

So, what I'd like to see is that we can run this against a store even if that store doesn't have the e2e tests installed.

So detect-e2e currently gates this against running if one isn't found, let's actually install the sample data and the e2e tests and attempt to run them.

@damienwebdev I've pushed a follow-up commit.

The workflow now:

• Continues normally when no E2E suite is present.
• Installs sample data when E2E is enabled.
• Installs the MageOS-adapted Playwright suite.
• Executes the Playwright tests.
• Removes the Node version pin.

I think this gets us much closer to the flow we discussed earlier today. Could you take another look when you have a moment? I suspect these changes might need tuning from where we are but this structure should be what we are aiming at. Once it works, I'll start 2 new activties:

• adding more Playwrights test on a weekly basis to start adding genuine tests coverage (this is something anyone can add to as well)
• start a E2E adapter so that any E2E tests suite can work. Lucas might want to join to add his test suite to work as an alternative

@damienwebdev I've removed the guards you mentioned. I understand this is so that we can discover fully the E2E execution path and identify what still needs to be wired up. I imagine we may reinstate some of these guards once E2E tests are fully integrated.

@Vinai asked two things:

• Is it possible, to use the built-in playwright version vs. installing our own?
• Is it possible to disable npm scripts to just lower the security surface concern?

@Vinai asked two things:

• Is it possible, to use the built-in playwright version vs. installing our own?
• Is it possible to disable npm scripts to just lower the security surface concern?

@Vinai , @damienwebdev My thoughts were that MageOS would own the E2E tests and the execution environment (Node, Playwright version, dependency installation, etc.) would be a separate concern.
I understand the concern around keeping the Node/npm security surface area as small as possible, and I'm happy to investigate those options once we've validated the E2E flow itself.

@digitalrisedorset

Thanks for the continued work on this. E2e test code is now running. Before I re-review, I need to see a green run of the Check Store Test workflow executed in your own fork, since fork PRs here don't run the full CI automatically.

Here's how to run it on digitalrisedorset/github-actions-magento2:

1. Enable Actions on your fork, go to the Actions tab and click "I understand my workflows, go ahead and enable them" if you haven't already.
2. Push your changes to feat/check-store-e2e-support on your fork.
3. Trigger the workflow, either:
   • Actions tab → "Check Store Test" → "Run workflow" → select branch feat/check-store-e2e-support, or
   • open a draft PR within your fork (feat/check-store-e2e-support → digitalrisedorset:main) so the pull_request trigger fires on every push.

Two notes:

• The pin in check-store.yaml pointing resolve-check-config at digitalrisedorset/github-actions-magento2/resolve-check-config@feat/check-store-e2e-support is correct for validation, it's what makes the fork run exercise your modified action instead of the published one on main. Keep it while you iterate, but it must be reverted to graycoreio/github-actions-magento2/resolve-check-config@main before this can merge.

Once you have a green run, link it here and I'll pick the review back up.